## UTDD → 写代码前先写单元测试

**适用场景**：你有一个具体函数要写，但不确定边界条件

**Prompt 模板**：
```
我需要写一个函数 <函数名>，功能是 <描述>
请先帮我写出这个函数的单元测试，包含以下测试用例：
1. 正常输入 → 期望输出
2. 边界值（如空字符串、0、最大值）
3. 异常输入 → 期望如何处理

然后基于这些测试用例子来写实现代码。
```

**在 vibe coding 里的实际用法**：你告诉 AI "先别写实现，先写这个函数的测试"，AI 会先问清楚这个函数的输入输出是什么、有什么边界条件，等你确认后才开始写代码和测试。

---

## ATDD → 写代码前先定义验收标准

**适用场景**：产品提了一个需求，你不确定怎么实现，先把"怎么做算完成"说清楚

**Prompt 模板**：
```
我有一个用户故事：
"<用户角色> 想要 <功能>，以便 <价值>"

请帮我从以下角度补充验收标准：
1. 正常流程：用户做 X → 系统应该 Y
2. 异常流程：用户做 X 出错了 → 系统应该 Z
3. 边界条件：什么情况下这个功能不能使用
4. 非功能性：性能/并发/兼容性要求

有了这些标准之后，我再让你写实现代码。
```

**在 vibe coding 里的实际用法**：你把一段 PRD 丢给 AI，让它先输出"怎么做算完成"，你确认后再让它写代码。这解决的是"功能没错但不是我要的"问题。

---

## TDD → 写完代码必须跑通测试，不通过不能算完成

**Prompt 模板**：
```
按照以下测试用例实现这个功能：
<粘贴或描述测试用例>

要求：
1. 先写实现代码
2. 运行测试
3. 如果测试失败，分析原因并修正代码
4. 重复直到所有测试通过
5. 最终提交前必须保证所有测试通过
```

**在 vibe coding 里的实际用法**：你让 AI 同时写实现和测试，然后 AI 自我验证 — 这也是第三个视频里 SDD 的 Verify 阶段的核心：AI 生成的代码要能通过根据规范自动生成的测试用例。

---

## BDD → 需求描述用 Given-When-Then，精确到 AI 无法自由发挥

这个你看过，核心是把"好玩"、"好用"这种模糊形容词变成可验证的描述：

```
Given（初始状态）: <描述系统或用户处于什么状态>
When（触发动作）: <当用户做了什么操作时>
Then（期望结果）: <系统应该产生什么结果>

例如：
Given：棋盘上有1点血吸血鬼，邻格有10点血敌方主将
When：吸血鬼攻击一次敌方主将
Then：吸血鬼变成3点血，敌方主将变成8点血
```

**在 vibe coding 里的实际用法**：让 AI 把你的自然语言需求转写成 Given-When-Then，然后基于这个格式再写代码。好处是 AI 确认后再写，实现结果不会偏。

---

## 四个层次的对比

| 层次 | 问的问题 | 产物 | AI 视角 |
|------|---------|------|---------|
| **UTDD** | 这个函数对不对？ | 单元测试 + 实现 | "帮我先写测试，再写代码" |
| **ATDD** | 这么做算完成吗？ | 验收标准 + 实现 | "先说清楚怎么做算完成" |
| **BDD** | 具体场景是什么？ | Given-When-Then 场景 | "把这个需求翻译成可执行场景" |
| **TDD** | 写完能过测试吗？ | 测试驱动循环 | "必须跑通测试才算完成" |